Skip Headers

Oracle® Transparent Gateway for DRDA Installation and User's Guide 10g Release 2 (10.2) for UNIX Part Number B16217-02 |
Home | Book List | Contents | Index | Master Index | Feedback

Previous | Next
| View PDF

# 6 Configuring SNAP-IX Interfaces

This chapter describes configuring the SNAP-IX product on Solaris for usage with the Oracle Transparent Gateway for IBM DRDA. SNAP-IX provides SNA connectivity through the APPC/LU6.2 protocol between the Sun host and the remote DRDA Server. Read this chapter to provide information about creating server profiles.

This chapter contains the following sections:

- Checklist for Configuring the Communications Interfaces

- SNAP-IX Configuration Tool

- Creating SNAP-IX Profiles for the Gateway

- Independent Versus Dependent LUs

- Creating SNA Definitions for the Gateway

- Using SNA Session Security Validation

- SNA Conversation Security

- Testing the Connection

## Checklist for Configuring the Communications Interfaces

The checklists for configuring the communication interfaces are:

- Creating SNAP-IX Profiles for the Gateway

- Creating SNA Definitions for the Gateway

- Testing the Connection

## Before You Begin

This chapter requires you to provide values for parameters unique to your system in order to properly configure SNAP‑IX. Refer to Appendix E for a worksheet listing all of the installation parameters you will need to know before you can complete the configuration process. Ask your network administrator to provide you with these parameters before you begin.

## SNAP-IX Configuration Tool

All SNAP‑IX product configuration is done using the `xsnaadmin` program. This tool is an X-Windows application which provides a graphical interface so that you can view and modify the current SNAP‑IX configuration and the current running state of the host SNA node.

## Creating SNAP-IX Profiles for the Gateway

The Oracle Transparent Gateway for IBM DRDA requires a stored set of definitions, called Side Information Profiles, to support connections between the gateway and DRDA Servers. Each profile consists of a profile name and a profile type, which is a set of fields describing the profile. The fields in a given profile type are generally a mixture of operating parameter values and names of other SNA profiles relevant to the profile. Each functional part of APPC, such as the Mode, Remote Transaction Program name, and LU, is described by a distinct profile type.

## Independent Versus Dependent LUs

The gateway configuration can accommodate either independent LUs or dependent LUs. If you choose to use dependent LUs, or are restricted to using dependent LUs, the gateway will function properly; if a dependent LU is correctly defined, then you will need to make no alterations to the configuration of the Oracle Transparent Gateway for IBM DRDA, nor should any changes be needed to the DRDA Server. However, Oracle recommends using independent LUs for the Oracle Transparent Gateway for IBM DRDA because they support multiple parallel sessions or conversations. This means that multiple Oracle client applications can be active simultaneously with the same DRDA Server through the independent LU.

In contrast to independent LUs, dependent LUs support only a single active session. The Control Point for the Node (CP) queues each additional conversation request from the gateway behind an already active conversation. In other words, conversations are single-threaded for dependent LUs.

The operational impact of dependent LUs is that the first client application can initiate a conversation through the gateway with the DRDA Server, but while that session is active (which could be seconds, minutes or hours, depending on how the client application and transaction are designed), any other client application initiating a session with the same DRDA Server appears to hang as it waits behind the previous session.

If a production application really uses only a single conversation at any one time, then there should be no problem. However, at some point you might require additional concurrent conversations for testing or for other application development. Having more than one conversation requires that additional dependent LUs be defined on the remote host. Additional configuration entries will need to be added to SNAP‑IX. Additional Side Information Profiles should be defined to use the new dependent LUs. Oracle Transparent Gateway for IBM DRDA instances should be created and configured to use these new Side Information Profiles.

## Creating SNA Definitions for the Gateway

SNAP‑IX definitions are stored in the following two files, located in the directory `/etc/opt/sna`:

- `sna_node.cfg`: SNA node definitions

- `sna_domn.cfg`: SNA domain definitions

These files are created and maintained with the `xsnaadmin` tool. Maintenance of SNA definitions is normally done by a user with administrative authority. The following information is intended for the person creating SNA definitions for the gateway. You should have some knowledge of SNA before reading this section. To create the SNA definitions use the following information:

### Sample SNAP-IX Definitions

The `$ORACLE_HOME/tg4drda/sna/snapix` subdirectory contains a set of sample SNAP‑IX definitions for the gateway, created with the `xsnaadmin.` SNA definitions are very specific to the host and SNA network. As such, the sample definitions provided will not work without being tailored for the local host and SNA network.

### Configuring SNAP-IX

This section describes the process of creating your SNA definitions for SNAP‑IX, using `xsnaadmin.` All of the tasks described in this section are performed from within `xsnaadmin.`

All configuration is done using the various pull-down menus and panels in `xsnaadmin.` The following configuration descriptions follow the samples provided. Please tailor the various SNA values for your local host and SNA network.

Invoking `xsnaadmin`

Use the following commands to invoke `xsnaadmin.` The `$DISPLAY` environmental variable must be set appropriately. If you are running `xsnaadmin` from the local console, then `$DISPLAY` should already be set. If you are running `xsnaadmin` from a remote X display, then set `$DISPLAY` to the host name or IP address of that display.

    $ DISPLAY=xstation10.us.oracle.com:0
    $ export DISPLAY
    $ xsnaadmin &

Upon startup of `xsnaadmin,` the main screen will open and display the current configuration of the local SNA node. (See Figure 6-1)

Figure 6-1 `xsnaadmin` Main Screen

Description of "Figure 6-1 `xsnaadmin` Main Screen"

Configuring the SNA node

From the Services menu select Configure Node Parameters. In the Node Parameters dialog box (see Figure 6-2) enter the APPN support type, Control Point Name, Control Point Alias and Node ID as needed. The Control Point Name is composed of the SNA Network Name and the CP name of the local host. Click OK.

Figure 6-2 Node Parameters Dialog Box

Description of "Figure 6-2 Node Parameters Dialog Box"

Adding a Port

From the Services menu select Connectivity and New Port. In the Add to <nodename> dialog box (Figure 6-3), select the Port type and click OK.

Figure 6-3 Add to <nodename> Dialog Box

Description of "Figure 6-3 Add to <nodename> Dialog Box"

In the SAP dialog box (see Figure 6-4) enter a Port name and network card number. The Port name will be used to logically name the physical network card that you are using and will be used to bind a Service Access Port to the card for SNA protocols. Normally you can accept the values provided in the dialog box. If a different network card is needed, however, enter the card number as reported with the `dmesg` command. Click OK.

Figure 6-4 Token-ring SAP Dialog Box

Description of "Figure 6-4 Token-ring SAP Dialog Box"

Create a Link Station

After the Port has been defined, you need to create a Link Station. The Link Station represents the SNA node of the remote host of the DRDA Server. But before you can create the Link Station, you must create a Remote Node definition. From the Services menu select `APPC` and `Add Remote Node`. In the dialog box (see Figure 6-5) enter the SNA CPNAME of the remote node and click OK.

Figure 6-5 Add Remote Node Dialog Box

Description of "Figure 6-5 Add Remote Node Dialog Box"

Now you are ready to create the Link Station. From the Services menu, select Connectivity and New Link Station. In the dialog box (see Figure 6-6) select the Port previously defined and click OK.

Figure 6-6 Add Link Station Dialog Box

Description of "Figure 6-6 Add Link Station Dialog Box"

In the Link Station dialog box (see Figure 6-7) enter a name for the Link Station, choose the SNA Port name and choose the type of link activation. Choose the LU Traffic type. For maximum flexibility, choose the Any option. For Independent LU traffic, specify the Remote Node name. Click Remote node and select the node you previously created. Click OK. Choose the type of the Remote node, typically a network node. For Dependent LU traffic, specify the role of the remote node, typically 'host', the local node ID, and optionally, remote node ID. Then specify the Contact Information.

Figure 6-7 Link Station Dialog Box

Description of "Figure 6-7 Link Station Dialog Box"

Contact information contains the MAC address of the remote host as well as the SAP number. Click Advanced for additional parameters of the Link Station.

The Token Ring Parameters dialog box shows additional parameters of the Link Station (see Figure 6-8). These parameters effect initial XID contact and retransmission times and limits. The defaults are normally sufficient. Click OK.

Figure 6-8 Token Ring Parameters Dialog Box

Description of "Figure 6-8 Token Ring Parameters Dialog Box "

Create Local LUs

After the remote node definitions have been made, create the Local LU names for the local host. From the Services menu select APPC and New Local LU. In the dialog box (see Figure 6-9) enter the name of the local LU and an alias. This name must correspond to the VTAM definitions on the remote DRDA Server host for the UNIX host. Click OK.

Figure 6-9 Local LU Dialog Box

Description of "Figure 6-9 Local LU Dialog Box "

Create Partner LUs

Now define a Partner LU which represents the LU that the DRDA Server is using to communicate. From the Services menu select APPC and New Partner LUs and Partner LU on Remote Node. In the dialog box (see Figure 6-10) Enter the Partner LU name and characteristics. The Partner LU name will contain the SNA Network Name as well as the LU name of the remote LU. Enable parallel session support. The location is the name as the remote node name. You may click Location for a list. Then click OK.

Figure 6-10 Partner LU Dialog Box

Description of "Figure 6-10 Partner LU Dialog Box"

Create Mode and CPI-C Profiles

After the local and remote LU definitions have been made, create the necessary Mode and CPI-C definitions.

From the Services menu select APPC and Modes. In the Modes dialog box (see Figure 6-11) click New to add a new mode.

Figure 6-11 Modes Dialog Box

Description of "Figure 6-11 Modes Dialog Box "

In the Mode dialog box (see Figure 6-12) enter the mode name and other session parameters. The prescribed name for a DRDA mode is IBMRDB. Contact your remote host system administrator for appropriate mode parameters. Click OK.

Figure 6-12 IBMRDB Mode Dialog Box

Description of "Figure 6-12 IBMRDB Mode Dialog Box"

Now that the mode has been defined, create the CPI-C Side Information Profile, which the gateway will use as a connection name. From the menu, select APPC and CPI-C. In the CPI-C destination names dialog box (see Figure 6-13) click New to add a new profile.

Figure 6-13 CPI-C destination Names Dialog Box

Description of "Figure 6-13 CPI-C destination Names Dialog Box"

In the CPI-C destination dialog box, (see Figure 6-14) enter the profile name, local LU name, partner TP, partner LU and mode, and security option. The default TP name of the mode DRDA Server will typically be a service TP named `07F6C4C2`. For the local LU, you may specify a specific LU or choose the default LU. For the Partner LU, enter either the full LU name or the alias created previously. Enter `IBMRDB` for the mode name. Choose the type of security these sessions will use. This will affect how session authorization is done. Click OK.

Figure 6-14 CPI-C destination Dialog Box

Description of "Figure 6-14 CPI-C destination Dialog Box "

## Using SNA Session Security Validation

When the database link request for the gateway begins, the gateway attempts to start an APPC conversation with the DRDA Server. Before the conversation can begin, a session must start between the host LU and the DRDA Server LU.

SNA and its various access method implementations (including SNAP‑IX and VTAM) provide security validation at session initiation time, allowing each LU to authenticate its partner. This is carried out entirely by network software before the gateway and server application programs begin their conversation and process conversation-level security data. If session-level security is used, then correct password information must be established in the host Connection Profile and in similar parameter structures in the DRDA Server system that is to be accessed. Refer to the appropriate SNA server product documentation for detailed information.

## SNA Conversation Security

SNA conversation security is determined by the setting of the Gateway Initialization parameter, `DRDA_SECURITY_TYPE`. This parameter determines whether SNA security option `SECURITY` is set to `PROGRAM` or to `SAME`. Generally, the gateway operates under SNA option `SECURITY``=PROGRAM`, but it can also be set to operate under SNA option `SECURITY=SAME`.

### SNA Security Option SECURITY=PROGRAM

If `DRDA_SECURITY_TYPE``=PROGRAM` is specified, then the gateway allocates the conversation with SNA option `SECURITY=PROGRAM` and sends information to the DRDA Server:

- If the database link has explicit `CONNECT` information, then the specified user ID and password are sent.

- If the database link has no `CONNECT` clause and if the application has logged in to the Oracle integrating server with an explicit user ID and password, then the Oracle user ID and password are sent.

- If the application logs in to the Oracle integrating server with operating system authentication, and if the database link lacks explicit `CONNECT` information, then no user ID and password are sent. If no user ID and password are sent, and if the DRDA Server is not configured to assign a default user ID, then the connection fails.

In general, `SECURITY=PROGRAM` tells the DRDA Server to authenticate the user ID/password combination using whatever authentication mechanisms are available. For example, if DB2/OS390 is the DRDA Server, then RACF can be used. This is not always the case, however, because each of the IBM DRDA Servers can be configured to process inbound user IDs in other ways.

### SNA Security Option SECURITY=SAME

If `DRDA_SECURITY_TYPE``=SAME` is specified, then the gateway allocates the conversation with SNA option `SECURITY=SAME`, and the following information is sent to the DRDA Server:

- If the database link has explicit `CONNECT` information, then the specified user ID is sent.

- If the database link has no `CONNECT` clause, and if the application has logged into the Oracle integrating server with an explicit user ID and password, then the Oracle user ID is sent.

- If the application logs in to the Oracle integrating server with operating system authentication, and if the database link lacks explicit `CONNECT` information, then no user ID is sent. If no user ID is sent, and if the DRDA Server is not configured to assign a default user ID, then the connection fails.

For this option to function properly, SNAP‑IX requires that the effective user ID under which the gateway is executing must be a member of the system group. In UNIX terms, this means that the user ID must be defined with its primary group set to `system`. In addition, the owning user ID of the gateway executable must be set to the desired effective user ID, and the set-uid bit of the executable file permissions must also be set. The `ls -l` command shows the owning user ID and the setting of the set-uid bit for the executable file. The owning user ID can be changed by the `root` user with the `chown` command, and the set-uid bit can be set using the `chmod u+s` command. The gateway executable, as installed by the Oracle Universal Installer, has its set-uid bit disabled.

The simplest way to cause the gateway to execute under an effective user ID that is a member of the system group is to change the owning user ID of the gateway executable to `root.` Another way is to change the primary group for the owning user ID of the gateway executable to `system.` However, be careful when choosing the user ID. Oracle recommends using `root` and recommends never changing the Oracle `dba` user ID primary group to `system.`

When the effective user ID is not a member of the system group, a failure is generated when the gateway attempts to allocate a conversation with the DRDA Server, and an error message is sent to the gateway user.

## Testing the Connection

Before proceeding with the gateway configuration tasks in Chapter 11, "Configuring the Gateway", ensure that your connection is working. Do this by starting the SNAP‑IX Node and then starting the individual link stations.

Figure 6-15 shows the relationship between SNAP‑IX definitions and the VTAM definitions on the remote host.

Figure 6-15 Relationship between SNAP-IX Definitions and Host VTAM Definitions

Description of "Figure 6-15 Relationship between SNAP-IX Definitions and Host VTAM Definitions"